home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000066_icon-group-sender _Thu Nov 5 04:55:57 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Sat, 7 Nov 1992 05:55:54 MST
  2. Date: 5 Nov 92 04:55:57 GMT
  3. From: uchinews!ellis!goer@speedy.wisc.edu  (Richard L. Goerwitz)
  4. Organization: University of Chicago Computing Organizations
  5. Subject: Re: file scanning
  6. Message-Id: <1992Nov5.045557.15162@midway.uchicago.edu>
  7. References: <01GQRAOSOAB48WWBJA@KUNRC1.URC.KUN.NL>
  8. Sender: icon-group-request@cs.arizona.edu
  9. To: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. >>One thing that's worth thinking about is whether string scanning could
  14. >>be extended to cover files.  That would solve your problem.
  15. > 
  16. >This was somewhat surprising to me, because I already do string
  17. >scanning on files.
  18. >
  19. >  !!inputfile ? while write(move(1))
  20.  
  21. This only gives us a character at a time, and isn't really and dif-
  22. ferent than saying "while c := reads(inputfile) do (something with
  23. c)."  This really isn't scanning (where you can move to arbitrary
  24. positions, perform analytical and synthetic operations, etc.).  What
  25. we are talking about is overloading the ? operator so that it can
  26. take an expression on its left that produces either a string or a
  27. file, so that if a file were produced, functions like move() would
  28. still work.  To work well, this would take a lot of seeking, and per-
  29. haps a little creative buffering, plus a whole lot of work on the
  30. machinery of scanning.
  31.  
  32. I think it's a neat idea, and I don't see how it would be the least
  33. bit un-Iconish.  It would sure make tokenizing a lot easier.  Even
  34. Icon's own tokenizer wouldn't work with scanning, but rather needs
  35. a character-driven finite-state machine.
  36.  
  37. Ken, Ralph, Clint, etc.:  How hard would it really be to implement
  38. file scanning?
  39.  
  40. -- 
  41.  
  42.    -Richard L. Goerwitz              goer%midway@uchicago.bitnet
  43.    goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
  44.